It is common practice in many industries to provide a backup data storage entity. In critical applications and industries, host entities often have multiple data storage entities coupled through a controller to a computer and operated in a mirrored (also known as shadowed) configuration. In a mirrored configuration, data storage entities are treated as pairs, and all data intended for a particular data storage device is duplicated on a block-for-block basis on the paired “mirrored” data storage entity. Mirroring can be accomplished by special circuitry or by computer program control, or a combination thereof.
One type of mirroring architecture is asynchronous mirroring. Using asynchronous mirroring, once a write command (hereafter referred to as a “write”) is received at a primary storage entity, a completion acknowledgment is sent directly back to an originating host entity to indicate that a subsequent write may be sent. However, this acknowledgment may not necessarily indicate that the write was received at (or even yet transmitted to) a remote storage entity. Instead, if the write is placed in the buffer of the primary storage entity, then the write is issued a sequence number indicating its position in relation to the other writes stored in the buffer. Subsequently, the write can be forwarded to the remote storage entity.
Another type of mirroring is synchronous mirroring. In contrast to asynchronous mirroring, a synchronous mirror primary storage entity delays sending acknowledgement (of having completed a write from the host entity) until the primary storage entity has received acknowledgement that the secondary storage entity has completed the write (that the primary storage entity had forwarded). Relative to asynchronous mirroring, synchronous mirroring delays the host from sending a second write until two storage entities (instead of merely one) in the chain have actually received a first write.
FIG. 1 illustrates a cascaded (also known as daisy-chained) asynchronous mirroring architecture 5, according to the Background Art. Architecture 5 includes a host entity 10 in communication with a primary storage entity 20. The primary storage entity 20 is in communication with a secondary storage entity 30. Primary storage entity 20 receives writes from host entity 10. Subsequently, the primary storage entity 20 passes these writes to secondary storage entity 30.
Sidefiles 50 and 70 are used at each of storage entities 20 and 30 in order to track writes received and forwarded by the respective storage entity 20 and 30. A sidefile includes fields for sequence numbers, location of the storage media (e.g., one or more tracks) and data. A sidefile operates to numerically and sequentially sort data sent to a respective storage entity before it is forwarded to a remote mirrored storage entity. When a write is received, it may be that the storage entity is unable at that time to immediately write the associated data to its storage media. In such a case, such received data will be stored in a buffer at the storage entity in order to allow the sender of such writes to continue sending writes to the storage entity uninterrupted. However, this buffered data should be sequenced so that it may be appropriately written to the storage medium of the storage entity.
As a write is placed in the primary storage entity's buffer, the write is assigned a sequence number that is stored and tracked within the sidefile. The sequence number may be coupled with associated pointers to the data (that is the subject of the write) and to a track(s) where the data must be written. At an earliest possible time, the primary storage entity references the sidefile to determine the oldest sequence number therein and sends at least the corresponding write to the remote storage entity. Once execution of a write associated with a specific sequence number in the sidefile is completed at the remote storage entity, then a pointer 52 will be updated to indicate a next sequence number (NSN) that should be next applied to the remote storage entity. Pointer (hereafter, an NSN pointer) 52, for example, is illustrated immediately adjacent to sidefile 50. Similarly, sidefile 70 has an NSN pointer 72.
Writes communicated from primary storage entity 20 to secondary storage entity 30 will now be discussed in detail. It is assumed that primary storage entity 20 and secondary storage entity 30 are in paired status. That is, any writes received at primary storage entity 20 are necessarily sent to secondary storage entity 30. As a write at primary storage entity 20 is applied to a storage medium thereof, primary storage entity 20 also initiates a communication of this write to secondary storage entity 30. In FIG. 1, such propagation of writes from primary storage entity 20 to secondary storage entity 30 is represented by the sequence numbers, e.g., 1, 2, 3 and 4, being illustrated next to communication path 32 therebetween. As the writes are sent from primary storage entity 20, NSN pointer 52 to sidefile 50 is remapped accordingly. It should be noted that the sequence numbers 1, 2, 3 and 4, at this time, still remain in sidefile 50.
As writes are received at secondary storage entity 30, they are written to sidefile 70. According to the example circumstances of FIG. 1, sidefile 70 indicates that the write associated with sequence number 1 sent from primary storage entity 20 is accounted for. Once this occurs, secondary storage entity 30 may transmit an acknowledgment to primary storage entity 20 that the sequence number 1 and its associated write is accounted for at secondary storage entity 30. Upon receipt of this acknowledgment, primary storage entity 20 is at liberty to remove the sequence number 1 from sidefile 50.